既然如此，我們會用怎樣的方式去現形並檢視順暢度呢？在 Scrum 中最常搭配的實踐，就是比較耳熟能詳的 Velocity 了吧？或許稱之為速率表、速度、Capacity、Throughput 等名稱，但指的多是同樣或類似的概念—也就是單位時間內，團隊交付的張數或工作量。

這邊先採用 Velocity 這個多數人比較慣用的稱呼，但實務上我比較喜歡敏捷開發的藝術裡提到的 Capacity 的用法，可以參見下面的摘要：

產能一開始稱為速度（Velocity）。因為「速度」暗指某種不存在的控制程度，所以我不再使用該術語。想想看一台車：只要踩下油門，便可以輕鬆地提升速度。不過如果你想要增加車子的容量，你需要做出更大的改變。團隊產能也是如此。他並不是如此輕易可以改變的事物。

————摘自《敏捷開發的藝術》中文版，第 225 頁

在進一步探討前，先來對齊 Velocity 的認知吧的認知吧！

定義

Velocity 是一種預測值，用來表示一個團隊在一個迭代可以確實完成多少的工作。

————改自《敏捷開發的藝術》中文版，第 225 頁

Sprint Planning 時，團隊會預測當個 Sprint 可以做完的量，認領後在接下來的 Sprint 中，致力於交付這些待辦事項。這是一個理想的願景，但實務上團隊又怎麼知道自己一個 Sprint 能夠交付多少工作量的項目呢？

這時候通常就會搭配另外一個實踐——相對估算。透過相對估算與故事點（story points）的概念，使每一個待辦項目的工作量量化，常見的是將相對級別對應到調整過後的費式數列 1, 2, 3, 5, 8, 13, 20, 40, 100。

接下來就仰賴經驗主義（empiricism），透過近數次 Sprint 交付的待辦項目的總工作量的平均，作為預測下一次 Sprint 能夠交付工作量的預測值。

為了避免有些讀者對於估算的概念還不熟，就來舉個例子吧！

舉例

當一個 Sprint 結束時，可以看到產品待辦項目（PBI）大致會分為三種狀態：

1. 待辦：還沒有開工
2. 進行中：但還沒做完；通常會延到下週去做
3. 已交付：以符合 Scrum Team 對完成的定義，已交付給 Stakeholder

每個產品待辦項目都會透過相對估算後，得出對應工作量級別的數字，加總起來後，這三種狀態分別為 14、32、36。那此時 Velocity 該怎麼算得呢？上圖其實已經先給出了答覆，也就是只計算「已交付」的工作量。

通常這時候開發團隊就會抗議：「我這不是還有 32 點是做一半的嗎？那也算是我這週交付的工作量呀！」這句話並沒有錯，但是實務上該怎麼算？把每個進行中的產品待辦項目都重新估算一次嗎？這樣的成本是符合效益的嗎？有沒有更簡單的做法？

在回答這個疑惑前，先將時間軸度看更遠一點。

這是 4 次 Sprint 已交付待辦項目的數量、工作量大小與 Velocity。

到這邊，有個脈絡與原則要把持住，現在要計算 Velocity 的目的是為了協助團隊預測下一個 Sprint（比如說這個案例是 Sprint 5）能夠交付多少工作量。並不是要監控團隊每個 Sprint 的交付量與進度。

如果是基於這樣的認知，那我其實只要將過去 4 次的 Velocity 平均起來，我就可以得到足夠參考價值的數值，用作下一個 Sprint 的預測值。畢竟這個 Sprint 有太多進行中的待辦項目，通常也會在下個 Sprint 被交付，如上圖 Sprint 1 ~ 2，以及 Sprint 3 ~ 4 的變化。

以這個案例為看，為了預測 Sprint 5 可能交付的工作量，這裡將近四次的 Velocity 加總平均起來，得到了 36 點，所以在下個 Sprint 可以先只認領 36 點工作量左右的待辦項目範疇就好。不用像第 1 個 Sprint 認領了 82 點，卻有超過一半是做不完的，更有近四成是做到一半的在製品！

這樣的做法不但可以省去重算每個 Sprint 進行中的產品待辦項目的工作量，也可以得到相對穩定的數值，不會因為某次 Sprint 的偏差而失準（如上圖的 Sprint 3）。

而且藉由只計算已交付的產品待辦項目，也讓團隊專注在減少在製品，先把已經展開的產品待辦項目完成，這樣每個 Sprint 的 Velocity 也會更加穩定。

🔍 避免產生在製品
在敏捷開發的實踐裡，通常會建議要避免產生在製品，盡量降低在製品的數量。與其去展開一個還沒開始的產品待辦項目，不如與其他人先合力完成進行中的項目，這樣就能因此在一個週期交付更多的產品待辦項目，及早交付、及早產生價值或是驗證市場。

另外，會採用敏捷開發的產品開發環境裡，通常市場變化速度都是快的，每個週期產品待辦項目的優先順序都可能不同。如果開發團隊產出了在製品到下個 Sprint，但其實已經有優先度更高的產品待辦項目產生，這種情況下，Product Owner 該讓團隊先繼續完成做到一半的產品待辦項目，還是捨棄那些項目，先做優先度變高的新項目呢？其實這樣在製品的產生，用極端一點的話語來形容，這就是在綁架 PO 的決策，混淆角色的職責。

現形

每個產品待辦項目的狀態、工作量大小的估算、在第幾個 Sprint 交付，就像是昨天前天所聊到「無形 → 數據 → 指標 → 圖表 (有形)」中的數據，而 Velocity 就是指標。

那下一步如何讓這些指標更加易懂以及更具存在感呢？明天我來分享過去工作經驗中，是怎麼演化 Velocity 紀錄與展現方式的，透過這種方式我拿到什麼好處、又遇上什麼困境吧！